1. Field of the Invention
Our invention relates generally to packet networks that support multiple traffic classes. More particularly, our invention relates to dynamic bandwidth reallocation among the traffic classes of a path within a packet network wherein the dynamic reallocation occurs without having to physically reconfigure the network.
2. Description of the Background
Enterprises have traditionally used connection-oriented ATM/Frame-relay based networks for their intranet and extranet applications, such as interconnecting remote sites, because these technologies provided guaranteed quality of service. However, because of the ubiquity of IP (internet protocol) based networks and the lower costs associated with these networks, enterprises are turning to virtual private networks (VPNs) offered by Internet Service Providers (ISPs) as an alternative way to interconnect remote sites. The problem with IP based VPNs however, is that they do not inherently provide the guaranteed quality of service offered by ATM and Frame-relay.
As a result, ISPs are deploying a combination of Diffserv (Differentiated Services) and MPLS (Multi-protocol Label Switching) based technologies in their IP networks to help provide the necessary quality of service guarantees. MPLS allows for the provisioning of label switched paths (LSPs) between pairs of edge routers in the ISP's network. Advantageously, MPLS provides a finer degree of control than traditional IP routing and as a result, allows the ISP to configure the LSPs along specifically engineered network paths such that each LSP is ensured a minimum bandwidth. Once the engineered LSPs are provisioned, the ISP uses the LSPs to provide customer VPN services such that the expected aggregate VPN traffic-demand from a set of customers along any given LSP does not exceed the LSP's minimum bandwidth, thereby ensuring each customer's VPN service has a guaranteed quality of service.
Diffserv works in combination with internal network router mechanisms, such as weighted fair queuing (WFQ) and dynamic round robin (DRR), to provide traffic/service classes within a network. Traffic classes are a way to treat various types of traffic differently and, of particular interest here, provide a way to create guaranteed bandwidth classes along a network link's fixed bandwidth. Diffserv, for the purposes of this discussion, provides policing and marking functions at the edge routers of an ISP's network. ISP customers subscribe to one or more traffic classes and an expected amount of bandwidth for each traffic class. In accordance with the subscribed services, Diffserv classifies and marks each data packet entering the network according to the different classes and polices the packets to ensure a customer is not exceeding its requested bandwidth. The internal network router mechanisms process each data packet in accordance with its corresponding traffic class.
The combination of MPLS, Diffserv, and WFQ/DRR allows for the creation of LSPs with engineered bandwidth where the bandwidth of each LSP is allocated and policed among different traffic classes. As a result, ISPs now offer VPN services using LSPs that provide guaranteed quality of service and where the VPN customer traffic is segregated among different traffic classes of the LSP. Diffserv marks the customer traffic based on the contracted services and polices customer access to each LSP by ensuring the customer traffic does not exceed service contracts for any one traffic class within the LSP.
In this combined environment, an ISP estimates the expected aggregate customer VPN traffic demand between pairs of edge routers and creates an engineered LSP between each edge router pair based on these estimates. In addition, the ISP estimates the bandwidth requests customers will make for each traffic class within an LSP. Based on the aggregate view of the LSP, the ISP then configures the WFQ/DRR mechanisms of the internal routers to support the estimated bandwidth for each traffic class of the LSP.
Customers requesting new VPN service specify to the ISP the remote sites to be interconnected and a set of bandwidth requests for one or more traffic classes between the sites. After mapping the VPN service request to an LSP that can interconnect the customer sites and prior to provisioning the new VPN service request, the ISP next determines whether the traffic classes of the chosen LSP can support the corresponding bandwidth requests. Specifically, the ISP takes into consideration the bandwidth being utilized by other customer traffic currently assigned to the LSP. The ISP may do this by tracking the aggregate bandwidth requests for each VPN service request mapped to the LSP or it may monitor the network to determine an LSP's current utilization of the traffic classes. If the bandwidth utilization for each traffic class is low enough to support the new VPN service request, the ISP accepts/admits the customer request, at which point a provisioning system performs Diffserv based policing/marking configurations on the corresponding edge routers so that the new incoming traffic is properly marked and policed per the service agreement. Accordingly, the edge routers assign and mark the incoming traffic according to a traffic class. The customer traffic is then directed to the appropriate outgoing LSP where it shares resources with the other customer traffic.
If however, one or more LSP traffic classes are over utilized such that they cannot support the additional bandwidth of the newly requested VPN service without degrading overall quality of service, the VPN service request is rejected/not admitted. Importantly, the VPN service request is rejected even if one or more traffic classes in the LSP are under utilized. The reason for this is because the WFQ/DRR configurations assigning bandwidth among the LSP traffic classes are static. In other words, once assigned, the bandwidth cannot be reallocated without performing reconfiguration of the routers. Hence, one way for the ISP to admit the new VPN service request is to reconfigure the WFQ/DRR mechanisms of the internal network routers to transfer bandwidth from the lower-utilized traffic class(es) to the higher-utilized class(es) based on the traffic demand. However, frequent reconfigurations of in-service routers is not advisable due to the error-prone effort involved, provisioning delays, potential risks to network stability, etc. As a result, an ISP will often deny the new service request, leaving its network under utilized. Hence, a VPN service request may be denied if sufficient bandwidth does not exist for a traffic class, even when other classes on the same LSP are not fully utilized and have sufficient bandwidth that could be used to meet the request.